Method and system for delayed allocation of resources

ABSTRACT

The present invention allows a server to delay allocating resources to a client&#39;s request. When the client requests a feature that requires server resources, the server accepts and acknowledges the client&#39;s request, but the client is prohibited from using the requested feature until further notice from the server. For example, during an authorization process, the server allocates only the minimum resources required to maintain the session and to authorize the client. Thereafter, the server allocates the resources necessary to support the client&#39;s request only when the resources become available. Until then, the server maintains the communications session without supporting the request. Thus, the server shepherds its resources rather than committing them at the whim of a client. Also, a client need not repeat its request if the server cannot immediately satisfy it; instead, the server accepts the request and then later begins to support it when adequate resources become available.

RELATED APPLICATION

The present application claims the benefit of U.S. Provisional PatentApplication 60/451,151, filed on Feb. 28, 2003, which is incorporatedherein in its entirety by reference.

TECHNICAL FIELD

The invention relates generally to network communications and, moreparticularly, to allocating resources among clients and servers on anetwork.

BACKGROUND OF THE INVENTION

The rapid growth of computer networks, both public and private, inrecent years has been spurred, in large part, by “client/servercomputing.” In this model, one computing device, the client, requeststhat another computing device, the server, provide services or featuresto it. Note that “client” and “server” are used solely to denote theparties in a request transaction. While some computing devices areimplemented as dedicated servers that can serve multiple clients, aclient and a server can switch roles from one transaction to another. Ina “peer-to-peer” network (common, for example, among devicescommunicating via short range radio), every computing device has thepotential to be both a client and a server, serially or simultaneously.

Servers often have to allocate precious resources to fulfill a requestfor a feature or for a service. Upon receiving a request from a client,a server checks the availability of its resources. Traditionally, if theserver does not have the resources to fulfill the request, then theserver rejects the request. If the client can proceed without therequested feature or service, then it does so and resubmits the requestlater, at which time the server may have the necessary resourcesavailable to fulfill the request.

In order to ensure that precious server resources are dedicated only tothose clients authorized to use them, servers often check the identityof a client making a request. If the client cannot authenticate itselfto the satisfaction of the server, then the server rejects the request.

This protection against unauthorized clients is not perfect, however.Some types of requests are made before the authorization process iscomplete. Processing these requests, even if they are ultimatelyrejected, consumes some level of server resources. For example, anefarious client could bring a “denial of service” (DOS) attack againsta server by repeatedly making requests of the server. Although thisclient will fail to authenticate itself and its requests will ultimatelybe rejected, the server may in the mean time utilize so many resourcesattempting to authenticate the client during each request that theserver exhausts its resource pool until the server is rendered incapableof fulfilling any requests, even those made by authorized clients.

SUMMARY OF THE INVENTION

In view of the foregoing, the present invention allows a server to delayallocating resources to a client's request. When the client requests aservice or a feature that requires server resources (such as, forexample, encryption or compression of the messages between the clientand the server), the server accepts and acknowledges the client'srequest, but the client is prohibited from using the requested featureuntil further notice from the server. For example, during anauthorization process, the server allocates only the minimum resourcesrequired to maintain the session and to authorize the client.Thereafter, the server allocates the resources necessary to support theclient's request only when the resources become available. Until then,the server maintains the communications session without supporting therequest. Thus, the server shepherds its resources rather than committingthem at the whim of a potentially malicious, malfunctioning, ormisconfigured client. Also, a legitimate client need not repeat itsrequest if the server cannot immediately satisfy it; instead, the serveraccepts the request and then later begins to support it when adequateresources become available.

According to one embodiment, after receiving a request for datacompression from a client, the server accepts and acknowledges therequest but delays allocating the resources necessary to compresscommunications data. Indeed, the server might not even check to seewhether resources are available until the client has successfullyauthenticated itself to the server. Even though the compression requesthas been accepted, the client and server communicate without compressingtheir data. This continues until, and if, the resources necessary forcompression become available on the server. At that time, the serverallocates the necessary resources and indicates to the client thatcompression is now supported. The server can signal this by, forexample, sending compressed data to the client. Upon receiving thesignal (e.g., the compressed data), the client realizes that it is nowpermitted to communicate with compression. The client responds bybeginning to transmit compressed data to the server.

Compression is just one example of a communications feature that can berequested by a client. Other examples include the wide range of featurescommonly called Quality of Service (QOS). QOS features include,generally, bandwidth, response time guarantees, immunity to error,integrity of message sequence and lack of duplication, maximumpermissible loss rates, and the like. QOS features provide exampleswhere, in keeping with one embodiment of the present invention, theserver can allocate resources level by level rather than all at once.For example, the client requests a great amount of guaranteed bandwidth.The server initially accepts the request but allocates resourcessufficient to support only a low amount of guaranteed bandwidth. Theclient recognizes this and uses only the low amount of bandwidth. Later,the server allocates more bandwidth to this client (in response, forexample, to another client releasing bandwidth), and the client beginsto use the greater bandwidth amount.

Also in keeping with the invention, a server or a client (or both)maintains information about the requested feature and about the actuallevel of service being supported. The server monitors this informationfor each client and allocates additional resources to the clients asresources become available in order to more fully support the clients'requests.

A client can display to its user the status of requests as accepted andsupported, accepted but not yet supported, and rejected. The server canprovide similar information to an administrator or to a log file.

BRIEF DESCRIPTION OF THE DRAWINGS

While the appended claims set forth the features of the presentinvention with particularity, the invention, together with its objectsand advantages, may be best understood from the following detaileddescription taken in conjunction with the accompanying drawings ofwhich:

FIG. 1 is a block diagram of an exemplary computer networkingenvironment within which the present invention can be practiced;

FIG. 2 is a schematic diagram generally illustrating an exemplarycomputer system that supports the present invention;

FIGS. 3 a and 3 b together form a data-flow diagram illustrating anexemplary message exchange between a client and a server duringnegotiation of the client's communications feature request;

FIG. 4 is a data-structure diagram of an exemplary message exchangedbetween the client and the server during the scenario of FIGS. 3 a and 3b;

FIGS. 5 a and 5 b together form a flowchart illustrating an exemplaryresource allocation method performed by a server;

FIG. 6 is a data-structure diagram of a request status list usable by aserver; and

FIGS. 7 a and 7 b together form a flowchart illustrating an exemplaryfeature request method performed by a client; and

DETAILED DESCRIPTION OF THE INVENTION

Turning to the drawings, wherein like reference numerals refer to likeelements, the present invention is illustrated as being implemented in asuitable computing environment. The following description is based onembodiments of the invention and should not be taken as limiting theinvention with regard to alternative embodiments that are not explicitlydescribed herein.

In the description that follows, the present invention is described withreference to acts and symbolic representations of operations that areperformed by one or more computing devices, unless indicated otherwise.As such, it will be understood that such acts and operations, which areat times referred to as being computer-executed, include themanipulation by the processing unit of the computing device ofelectrical signals representing data in a structured form. Thismanipulation transforms the data or maintains them at locations in thememory system of the computing device, which reconfigures or otherwisealters the operation of the device in a manner well understood by thoseskilled in the art. The data structures, where data are maintained, arephysical locations of the memory that have particular properties definedby the format of the data. However, while the invention is beingdescribed in the foregoing context, it is not meant to be limiting asthose of skill in the art will appreciate that various of the acts andoperations described hereinafter may also be implemented in hardware.

The present invention allows a server to accept a client request but todelay allocating the resources necessary to support that request. FIG. 1gives an example of a computer networking environment 100 in which theinvention can be used. The example network 100 includes a servercomputing device 102 and three client computing devices 104, 106, and108. The network 100 can be a corporate local area network (LAN), awireless network, the Internet, or anything in between and can includemany well known components, such as routers, gateways, hubs, etc. In anexample transaction, the client 104 requests a service or acommunications feature from the server 102. The server 102 provisionallyaccepts the request but does not allocate resources to support therequested feature until, for example, the client 104 authenticatesitself to the server 102 or until the resources become available. Untilthe resources are allocated and the server 102 informs the client 104 ofthat fact, the client 104 and the server 102 communicate without usingthe requested feature. Thus, the server 102 shepherds its resourcesrather than committing them at the whim of a potentially malicious,malfunctioning, or misconfigured client.

In another transaction, the client 104 and the server 102 can switchroles with the “server” 102 requesting a service from the “client” 104.In a peer-to-peer network, every computing device can be both a clientand a server, serially or simultaneously. Accordingly, embodiments ofthe invention can be practiced on clients, servers, peers, or anycombinations thereof.

The computing device 110 is another server but one that only directlycommunicates with the server 102 to provide resources to it. Itspresence illustrates that by following the methods of the presentinvention, the server 102 shepherds not just its own resources but theresources of the networking environment 100 generally.

The computing devices 102 and 104 of FIG. 1 may be of any architecture.FIG. 2 is a block diagram generally illustrating an exemplary computersystem that supports the present invention. The computer system of FIG.2 is only one example of a suitable environment and is not intended tosuggest any limitation as to the scope of use or functionality of theinvention. Nor should the computing device 102 be interpreted as havingany dependency or requirement relating to any one or combination ofcomponents illustrated in FIG. 2. The invention is operational withnumerous other general-purpose or special-purpose computing environmentsor configurations. Examples of well known computing systems,environments, and configurations suitable for use with the inventioninclude, but are not limited to, personal computers, servers, hand-heldor laptop devices, tablet devices, multiprocessor systems,microprocessor-based systems, set-top boxes, programmable consumerelectronics, network PCs, minicomputers, mainframe computers, anddistributed computing environments that include any of the above systemsor devices. In its most basic configuration, the computing device 102typically includes at least one processing unit 200 and memory 202. Thememory 202 may be volatile (such as RAM), non-volatile (such as ROM orflash memory), or some combination of the two. This most basicconfiguration is illustrated in FIG. 2 by the dashed line 204. Thecomputing device 102 may have additional features and functionality. Forexample, the device 102 may contain additional storage (removable andnon-removable) including, but not limited to, magnetic and optical disksand tape. Such additional storage is illustrated in FIG. 2 by removablestorage 206 and by non-removable storage 208. Computer-storage mediainclude volatile and non-volatile, removable and non-removable, mediaimplemented in any method or technology for storage of information suchas computer-readable instructions, data structures, program modules, orother data. Memory 202, removable storage 206, and non-removable storage208 are all examples of computer-storage media. Computer-storage mediainclude, but are not limited to, RAM, ROM, EEPROM, flash memory, othermemory technology, CD-ROM, digital versatile disks, other opticalstorage, magnetic cassettes, magnetic tape, magnetic disk storage, othermagnetic storage devices, and any other media that can be used to storethe desired information and can be accessed by the computing device 102.The device 102 may also contain communications channels 210 that allowthe computer to communicate with other devices. Communications channels210 are examples of communications media. Communications media typicallyembody computer-readable instructions, data structures, program modules,or other data in a modulated data signal such as a carrier wave or othertransport mechanism and include any information delivery media. The term“modulated data signal” means a signal that has one or more of itscharacteristics set or changed in such a manner as to encode informationin the signal. By way of example, and not limitation, communicationsmedia include wired media, such as wired networks and direct-wiredconnections, and wireless media such as acoustic, RF, infrared, andother wireless media. The term “computer-readable media” as used hereinincludes both storage media and communications media. The computingdevice 102 may also have input devices 212 such as a keyboard, mouse,pen, voice-input device, tablet, touch-input device, etc. Output devices214 such as a display (which may be integrated with a touch-inputdevice), speakers, and printer may also be included. All these devicesare well known in the art and need not be discussed at length here.

FIGS. 3 a and 3 b together show an exemplary exchange of messages whenthe client 104 requests a feature from the server 102. FIGS. 5 a, 5 b, 7a, and 7 b, below, present further details of possible messageexchanges. The client 104 requests the feature in step 300 of FIG. 3 a.The feature can be of any type including data compression, dataencryption, and the numerous QOS features. The message protocol can alsobe of any type, such as, e.g., SIP (the Session Initiation Protocol).Note that the feature request in step 300 need not be explicit: It mayinstead be implied by the message protocol used between the client 104and the server 102.

In step 302, the server 102 receives the feature request and decideswhether it will support that feature. If not, then the server 102 usesthe methods defined in the protocol to reject the request (not shown).If the server 102 will support the requested feature and is ready to doso immediately, then the server 102 allocates the resources needed tosupport the feature and accepts the request (also not shown). Thescenario depicted in FIGS. 3 a and 3 b concerns a third possibility forthe server 102: It may be willing to support the requested feature inthe future but is not yet ready to do so. One example that leads to thisscenario is the case where the server 102 currently does not have theresources available to support the feature but expects to acquire thoseresources soon. In another example, the server 102 does not yet trustthe client 104 enough to allocate precious resources to its request. Theserver 102 does not yet allocate the resources but waits until theclient 104 has successfully authenticated itself. (See the discussion ofsteps 310 and 312 of FIG. 3 b below.) In the scenario of FIG. 3 a, theserver 102 in step 302 sends a message to the client 104 indicating thatthe request has been accepted but also indicating that the requestedfeature is not yet supported.

There are numerous ways in which the server 102 can indicate that therequested feature is not yet supported. In SIP, for example, when datacompression is allowed on a communications link, “tags” are added to thedata fields. (See FIG. 4 and the accompanying discussion.) Not all datamessages are compressed even when compression is enabled (for example, agiven message may be too short to benefit from compression), so a flagin a tag indicates whether the accompanying data are compressed.Embodiments of the present invention can use this tag and flag in step302: The acceptance message is tagged indicating that the request fordata compression has been allowed, but the data in that message are notcompressed, as indicated by the flag. In step 304, the client 104receives the acceptance message and notes that the requested feature isnot yet supported. In the data compression example, the tag indicatesthe acceptance of the request, but the lack of compression indicatesthat the server is not ready for compressed data.

In steps 306 and 308, the client 104 and the server 102 communicatewithout using the requested feature. Depending upon circumstances, thesesteps can continue for a long time (until, e.g., the server 102 acquiresthe necessary resources) or can be very short (e.g., only until theclient 104 successfully authenticates itself to the server 102).

Steps 310 and 312 of FIG. 3 b are, in one sense, optional but areincluded because they illustrate a scenario in which the methods of thepresent invention are very useful. During these steps, the client 104authenticates itself to the server 102 using the methods established bythe protocol they are using. (Many such methods are known in the art.)The server 102 is understandably reluctant to allocate preciousresources until these steps are complete. Although this scenario is notthe only one in which delayed allocation of resources proves valuable,it is one scenario closely tied to preventing DOS attacks.

Finally, in step 314 the server 102 decides to allocate the resources tosupport the client 104's request. In step 316, the server 102 indicatesto the client 104 that the feature is now supported. Just as with thenumerous possible indications discussed above with respect to step 302,there are numerous ways in which the server 102 can indicate that thefeature is now supported. Using the data compression example, the server102 can simply send compressed data to the client 104. Upon receivingthe indication, whatever it is, the client 104 notes that the feature isnow supported in step 318. From that point on, the client 104 and theserver 102 can communicate either using or not using the requestedfeature, as appropriate to the situation.

FIG. 4 shows a message data structure 400 used for sending compressed oruncompressed data. The data structure 400 includes three tag fields. Thefirst tag field 402 is designated for flags (herein “flags tag”). Theflags tag field 402 is used for indicating the format of the data infield 408, specifically whether the data are compressed. Under thisimplementation, the flag field includes mutually exclusive bits. As anexample, a 0x80 bit is used to indicate that the data are uncompressed,and a 0x20 bit indicates that the data are compressed.

In some embodiments, there are at least three types of data packets: (1)untagged data indicating that data compression is not available for thecurrent connection; (2) data tagged indicating that compression ispossible, but the data in field 408 are flagged as not compressed; and(3) data tagged indicating that compression is possible, and the data infield 408 are compressed. In steps 304 and 318 of FIGS. 3 a and 3 b,respectively, the client 104 determines the type of data packet itreceives from the server 102 to know whether or not data compression issupported.

A flowchart illustrating exemplary steps performed by the server 102 isshown in FIGS. 5 a and 5 b. In step 500, the server 102 receives arequest from the client 104 for a service or for a communicationsfeature. As mentioned above, this request may be in the form of anexplicit message sent by the client 104, or it may be implicit in thecommunications protocol used between the client 104 and the server 102.The server 102 checks, in step 502, its own configuration to see whetherit can support the requested feature. It could happen that the client104 is requesting a feature that the server 102 is not configured tosupport. In that case, the method proceeds to step 510 where the server102 rejects the request.

If the server 102 could, at least theoretically, support the requestedfeature, then in step 504 it accepts the request but tells the client104 that the client 104 may not yet use the feature.

There are some features that the server 102 will only provide toauthenticated clients. If the client 104 has requested such a feature,then in step 506 an authentication process is carried out. If the client104 fails the authentication in step 508, then the server 102 can rejectthe request in step 510, even though it provisionally accepted therequest earlier in step 504. Note that an authentication failure doesnot necessarily imply that the client 104 must terminate itscommunications session with the server 102. While that is a possibleoutcome, for the present discussion, the consequence of anauthentication failure is the client 104's inability to use therequested feature.

If the client 104 successfully authenticates itself to the server 102(or if such authentication is not necessary), then the client 104 andthe server 102 begin to communicate with each other but without usingthe requested feature. If necessary, the server 102 checks for theavailability of sufficient resources in step 512 and when, in step 514of FIG. 5 b, such resources become available, the server 102 allocatesthem to support the feature requested by the client 104. As mentionedabove in relation to FIG. 1, these resources need not reside on theserver 102 itself. They may be provided by another server 110. In somescenarios, the resources may become available in step 514 when anotherclient gives them up. In other scenarios, the resources are alwaysavailable, but the server 102 is reluctant to commit them to the client104 until the client 104 successfully authenticates itself in step 508of FIG. 5 a.

In step 516 of FIG. 5 b, the server 102 indicates that it is now readyto support the requested feature. Some features can be supported atdifferent levels. For example, the client 104 requests a minimumbandwidth guarantee of 512 kbps. If the server 102 does not have theresources to fully support that request, it could simply reject it.Alternatively, the server 102 can accept the request but tell the client104 that the server 102 can only support a 128 kbps bandwidth guarantee.The client 104 decides whether the lower guarantee is acceptable or notand reacts accordingly.

Throughout this procedure, the server 102 tracks its resource levels andallocations, as indicated in step 518. The server 102 uses thisinformation when deciding whether it has sufficient resources to supporta requested feature. System administrators use this information whendeciding whether the server 102 is optimally configured.

FIG. 6 gives an example of the server 102's resource log. The resourceallocation log 600 contains four entry rows, each one pertaining to asingle feature request. In the log 600, the client 104 (field 602) hasrequested data compression (field 604), and that request has beenaccepted (field 606). The client 106's request for data compression wasrejected, possibly because the client 106 failed to authenticate itselfto the server 102. The client 108's request for data compression hasbeen provisionally accepted, but that feature is not yet supported. Theclient 108 has made another request, this time for a guaranteedbandwidth of 512 kbps. The request has been accepted, but the feature iscurrently supported only at the lower level of 128 kbps.

In step 520 of FIG. 5 b, the client 104 and the server 102 can use therequested feature in their communications. However, they are notrequired to use the feature. For example, even when compression issupported, some messages are too short to benefit from being compressed.

Another use of the server 102's resource allocation log 600 isillustrated in step 522. Here, some resources are freed up (probablyfrom another client), and the server 102 checks its resource allocationlog 600. It notes, for example, that the client 108 requested 512 kbpsof guaranteed bandwidth but was only granted 128 kbps. If the server 102can and wishes to support the client 108's request at a higher level, itcan now do so. For some features, the server 102 can even use thismethod to reduce its level of support. Other features do not allow forthis, and the level of support must be renegotiated.

The client 104's side of a feature request transaction is illustrated inthe flowchart of FIGS. 7 a and 7 b. As the bulk of the client 104'sprocedure is evident in light of the above discussion of the server102's procedure, only a few aspects need be discussed here. The client104 can maintain a log of its own requests similar to the server 102'sresource allocation log 600 of FIG. 6. The status of feature requests,including their level of support if appropriate, can be displayed to auser of the client 104 as indicated in steps 716 and 720 of FIG. 7 b.

The above discussion focuses on the expected course of an exchangebetween the server 102 and the client 104. The following tableillustrates some of the unexpected things that can occur and how theclient 104 should react.

Potential Responses That the Client Should Be Prepared to Handle WhenRequesting a Feature Response Meaning Appropriate Handling Transactiontimeout. Negotiation Fall back to not using the Invalid response. hasfailed. requested feature on this Response with no link. indication ofthe requested feature. Response with an invalid indication of therequested feature. 400 The server does Fall back to not using the notsupport the requested feature on this NEGOTIATE link. method at thispoint in time or fails to recognize the method as valid. 405, 501 Theserver does Fall back to not using the not support the requested featureon this NEGOTIATE link. method. 488, 606 The server does not Fall backto not using the support the requested feature on this requestedfeature. link. 403 The server is Close the connection. Open denying thea new connection and do request. not request the feature. Do not use therequested feature on this link. 408, 480, 504 Timeout. Retry after asuitable delay. Multiple timeouts should result in closing theconnection and raising an appropriate alarm. This indicates loss ofconnectivity to the server. 1xx Provisional Ignore. response. 2xxSuccess. Enable the requested feature for this link. 3xx The server isIgnore. Fall back to not redirecting using the requested feature therequest. on this link. 4xx, 5xx, 6xx Other errors. Ignore. Fall back tonot using the requested feature on this link.

In view of the many possible embodiments to which the principles of thepresent invention may be applied, it should be recognized that theembodiments described herein with respect to the drawing figures aremeant to be illustrative only and should not be taken as limiting thescope of the invention. For example, those of skill in the art willrecognize that the illustrated embodiments can be modified inarrangement and detail without departing from the spirit of theinvention. Although the invention is described in terms of softwaremodules or components, those skilled in the art will recognize that suchmay be equivalently replaced by hardware components. Therefore, theinvention as described herein contemplates all such embodiments as maycome within the scope of the following claims and equivalents thereof.

1-43. (canceled)
 44. A method performed by a server to delay supportinga feature for a client until the client is authenticated, the methodcomprising: receiving from the client a request to use the feature;after receiving the request to use the feature, sending to the client anindication that the feature is not yet supported; and after sending tothe client the indication that the feature is not yet supported,determining whether the client is authenticated; upon determining thatthat client is not authenticated, suppressing allocation of resources tosupport the feature; and upon determining that that client isauthenticated, allocating resources to support the feature; and sendingto the client an indication that the feature is now supported.
 45. Themethod of claim 44 wherein the sending to the client an indication thatthe feature is not yet supported includes indicating that the request isgranted.
 46. The method of claim 44 including upon determining that theclient cannot be authenticated, sending to the client an indication thatthe client is not authenticated.
 47. The method of claim 44 includingupon determining that the client can be authenticated, sending to theclient an indication that the client is authenticated.
 48. The method ofclaim 44 wherein the received request to use the features indicates afirst level of support, and wherein the indication sent to the clientthat the feature is now supported indicates that the feature issupported at a second level of support.
 49. The method of claim 48wherein the second level of support is less than the first level ofsupport.
 50. The method of claim 49 further comprising after sending tothe client the indication that the feature is supported at the secondlevel of support, sending to the client an indication that the featureis supported at the first level of support.
 51. The method of claim 44wherein the feature is selected from the group consisting ofcompression, a quality of service, bandwidth, a response time guarantee,immunity to error, integrity of message sequence and lack ofduplication, and a maximum permissible loss rate.
 52. Acomputer-readable storage device storing computer-executableinstructions for controlling a client to obtain support from a serverfor a feature, by a method comprising: sending to the serverauthentication information of the client; sending to the server arequest to use the feature; and after sending to the server the requestto use the feature, receiving from the server an indication that thefeature is not yet supported; and after receiving from the server theindication that the feature is not yet supported, refraining from usingthe feature until receiving from the server an indication that thefeature is now supported.
 53. The computer-readable storage device ofclaim 52 wherein the receiving from the server of the indication thatthe feature is not yet supported includes receiving an indication thatthe request is granted.
 54. The computer-readable storage device ofclaim 52 including receiving from the server an indication that theclient is not authenticated when the server is unable to authenticatethe client based on the authentication information of the client. 55.The computer-readable storage device of claim 52 including receivingfrom the server an indication that the feature is now supported andafter receiving the indication that the feature is now supported, usingthe feature.
 56. The computer-readable storage device of claim 52wherein the sent request to use the feature indicates a first level ofsupport, and the received indication that the feature is now supportedindicates a second level of support of the feature that is less than thefirst level of support.
 57. The computer-readable storage device ofclaim 56 after receiving the indication that the feature is supported atthe second level of support, receiving from the server indication thatthe feature is supported at the first level of support.
 58. Thecomputer-readable storage device of claim 52 wherein the feature isselected from the group consisting of compression, a quality of service,bandwidth, a response time guarantee, immunity to error, integrity ofmessage sequence and lack of duplication, and a maximum permissible lossrate.
 59. A server that delays allocating resources for a featurerequested by a client until the client is authenticated, the methodcomprising: a memory storing computer-executable instructions of: acomponent that receives from the client a request to use the feature andauthentication information of the client; a component that, afterreceiving the request to use the feature, sends to the client anindication that the request is granted but that the feature is not yetsupported so that the client will refrain from using the feature untilthe client is sent an indication that the feature is now supported; anda component that, after sending to the client the indication that thefeature is not yet supported, when the client cannot be authenticatedbased on the received authentication information, suppresses allocationof the feature; and when the client is authenticated based on thereceived authentication information, allocates resources to support thefeature; and sends to the client an indication that the feature is nowsupported; and a processor that executes the computer-readableinstructions stored in memory.
 60. The server of claim 59 including acomponent that, when the client cannot be authenticated based on thereceived authentication information, sends to the client an indicationthat the client is not authenticated.
 61. The server of claim 59 whereinthe received request to use the feature indicates a first level ofsupport of the feature, and wherein the indication sent to the clientindicating that the feature is not yet supported indicates that thefeature is supported at a second level of support.
 62. The server ofclaim 61 further comprising after sending to the client the indicationthat the feature is supported at the second level of support, sending tothe client an indication that the feature is now supported at the firstlevel of support.
 63. The server of claim 62 wherein the feature isselected from the group consisting of compression, a quality of service,bandwidth, a response time guarantee, immunity to error, integrity ofmessage sequence and lack of duplication, and a maximum permissible lossrate.